FA設備技術勉強会で「試して分かった！AWS を使ったPLCのデータ収集と分析基盤の実践ノウハウ」について発表しました。

2023年03月26日(日)に「第13 回 FA設備技術勉強会 in けいはんな」という勉強会で「試して分かった！AWS を使ったPLCのデータ収集と分析基盤の実践ノウハウ」について登壇・発表をしました。
本記事は、その時に話した内容を少し加筆した形で書き起こしたものになります。

私自身は、製造業での勤務経験がないのですが、製造業向けの IoT 導入をいくつか担当させていただことがありました。これから製造業の方がクラウドを活用していこうと考えられた際に、私の経験から何らかのお役に立てればと思い、登壇させていただきました。
しかし、IT 系の勉強会やイベント以外での登壇は経験がなく、当日は激しく緊張していたためか会場へ向かう途中で腹痛に見舞われ、２回途中下車するというハプニングがありました。（開始時間までに到着できました）

セッションの内容

今回の登壇では、これまで私が製造業向けのお客様に IoT 導入を支援させていただいた中で分かった AWS 利用のノウハウや Tips についてご紹介しました。

AWS IoT SiteWiseの紹介

まず最初に産業機器のデータ収集としてサービスの候補に上がる「AWS IoT Sitewise」の特徴についてご紹介しました。

次に、AWS IoT Sitewise が提供する可視化ツールである「AWS IoT SiteWise Monitor」を画面サンプルと元に紹介しています。このページでは下記の可視化について説明しています。

• ステータスのタイムライン表示
• しきい値に応じた背景色の変更
• リアルタイムな折れ線グラフ
• データの変換や集計（5分間の平均値など）した値の表示

AWS IoT SiteWise Monitor によるダッシュボードの変更作業も直感的で、マウスによるドラッグアンドドロップで操作できるので、高い IT リテラシーを必要としません。

メリットの多いサービスのように思いますが、利用する際に注意点もあります。
時間の都合でセッション内では注意点の紹介はできませんでしたが、以前紹介した記事がありますので、そちらをご参考にしていただければと思います。

実際に直面した課題と対応

当初は、ここまで紹介してきた AWS IoT SiteWise を利用すれば簡単に「PLC のデータの収集〜可視化」ができると思っていましたが、実際に取り組んでみると想定外の課題が多くあり、現実は甘くありませんでした。

データ収集の課題

まず最初に「データ収集における課題」です。
そもそも、工場側の設備において OPC サーバが存在しないケースが多くありました。仮に OPC サーバの導入から取り組むにしても、OPC-UA のデータモデルに即したモデリングが必要で工数もかかることから、AWS IoT SiteWise の利用を断念するケースがありました。

OPC サーバがなくとも AWS IoT SiteWise を利用することは可能ですが、収集したデータを SiteWise ゲートウェイに渡すためのプロトコルアダプタ を実装する必要があります。自前で実装するなら SiteWise ゲートウェイを使う意味が薄れますが、回線切断時のデータバッファリングの機能などを利用したい場合もあると思います。自前で実装する場合でもどちらがいいか、先程提示した「SiteWise 導入時のポイント」も参考にしながら検討する必要があります。

実際には、SiteWise は使わず PLC から直接データを取得することを考えたのですが、PLC には多くの種類があり機種や型によって対応しているプロトコルも異なります。そのため対象 PLC がサポートしているプロトコルを調査、検証して実装することになりますが、IT 側から見ると製造業の プロトコルは初見のものが多く、その仕様を把握する所から始める必要があり、すぐに開発に入れない課題もありました。

逆に、仕様さえ把握できればデータ収集のアプリを開発することは問題なさそうなので、後は AWS のサービスと組み合わせることで拡張性の高いゲートウェイ開発ができるようになります。下記は PLC ではないですが、Modbus-RTU によるデータ収集を行う例としてご紹介しました。

開発に時間がかかりそうな場合は、既製品のゲートウェイを使って対応するケースもあります。その際の選択ポイントについてもご紹介しました。

最初は、MVNO 各社に対応している点です。工場のネットワークではインターネットに直接つながっていない閉鎖したネットワークとなっている場合があります。

要件的に許容できるなら、LTE や 5G で収集データを AWS に送ることができるので、既存ネットワークに対する変更も必要ありません。
弊社では利用実績のある SORACOM を最初に検討することが多いのですが、メリットの一つとして、SORACOM Napter というサービスによるリモートアクセスの容易さがあります。

また、SORACOM が提供する SIM を使えばマルチキャリアに対応しやすい点もメリットでした。一方で SoftBank 回線を利用する際は、デバイスがローミングをサポートしている必要があるので、SoftBank の利用が要件になっている場合は注意が必要です。

その他に、データ流量が多くなると SORACOM の利用料金も高くなるので、事前にトラフィックの見積もりを行い最適な SIM を選択することも重要なポイントになります。

次に「データの送信先」についてです。
収集したデータを活用するために、自分たちの AWS 環境や オンプレミスのサーバに送りたいケースがあると思います。
一方でデータの送信先が、ゲートウェイ提供元で展開されている IoT プラットフォームに限定されている場合もあります。この場合は、ユーザー側でデータ管理基盤などを作る必要がなくすぐに使えるメリットがありますが、データを活用する用途が多岐に渡るならば全てをサポートできなくなる場合があります。

場合によっては、CSV や API 経由でデータが取れる場合もありますが、取得できるデータの内容や API のレート制限などがないか、自分たちの要件を満たすかどうか確認が必要になります。

最後に、取得可能なデータ点数や種類についてです。
PLC から取得可能なデータは種類によって、1000 点以上取れるものもありますが、その全てをゲートウェイ側で取得できるか確認が必要なケースがありました。

また、データの取得方法についても確認が必要な場合があります。取りたいデータのアドレスを個々に指定できればよいですが、場合によっては「取得開始のアドレスから連続した 100 点まで」といった仕様となっている場合もあります。

このような場合は、PLC 側の設定を ゲートウェイの仕様に合わせる形で変更する必要があるので、データ取得を開始するまでに思わぬ時間がかかることがあります。

データの可視化の課題

次の課題は「データの可視化における課題」です。
特に製造業においては、業界独自の可視化パターンがあります。下記は Amazon Managed Grafana を使って「アンドン」と「生産進捗」の様子を可視化したものになります。
（生産進捗のグラフでは「１時間ごとの生産数と累積数」をプロットしています。画像では 5 分ごとにしています）

Grafana を使ってみた感想としては、GUI で操作できるが直感的ではない部分が多く難易度が高い、と感じました。
そのため、製造業向けの専用ツールを使うという選択肢もあると思います。
可視化という観点で見ると専用ツールを使ったほうが簡単にグラフ化できるメリットがあり、操作も直感的で、IT が苦手という方でも利用しやすくなるのではないでしょうか。

一方で、ツールの拡張性やライセンスコストは事前に確認しておくべき点になるかと思います。また、ツールをホスティングする環境次第ではサーバ運用や可用性などについても検討が必要になるので、トレードオフも含めて総合的な観点で比較検討する必要があります。

最後に、「クラウドのコストに関する課題」です。
今回、データ取得を検討した最初期では、次のような構成を検討しました。これは、AWS IoT Core で受け取ったデータを Amazon Timestream に入れるための設定が非常に簡単で、すぐに環境構築ができるためです。
また、Amazon Timestream はスキーマレスなので、送りたいデータ項目が増加しても データベース側は何も変更することがなく、運用工数が低いこともメリットとなります。

しかし、クラウドで提供されいてるマネージドなデータベースサービスでは、データのスキャンサイズに応じて課金が発生する場合があります。上記の Amazon Timestream も課金項目にスキャンサイズが含まれています。

この場合、問題になるのが「ダッシュボードの利用方法」になります。たとえば「5秒間隔でグラフを更新してニアリアルタイムに24時間表示し続ける」というケースを考えると、グラフを更新するたびに Grafana から Amazon Timestream にクエリが発行されて、1日で 17280 回もデータスキャンが実行されます。

スキャンするデータサイズにも関係する部分なので全てのケースが該当するわけではありませんが、スキャン頻度が多いと料金が想定以上に高くなることがあるので注意が必要です。

スキャンコストの抑止策の一つは、Amazon RDS や Amazon Aurora を使うことです。
RDS の場合、主な課金項目は「インスタンスの起動時間」と「ストレージサイズ」なので基本料金が高めになりますが、スキャンサイズによる課金は発生しないので、クエリ頻度を気にする必要がなくなります。
（クエリ頻度を気にしなくてもいいですが、RDS の負荷やパフォーマンスは監視しておくことが望まれます）

また、よくあるケースとして「とりあえず PLC で取れるデータは全てクラウドに送りたい」ということがあります。後で利用するかもしれなかったり、問題発生時のバックアップ用に取得しておきたいという背景がありますが、可視化という観点では、1000 点以上のデータをリアルタイムに可視化するのはあまり意味が無いように思われます。

そのため、リアルタイムに可視化するものと「月に１回」や「１日１回」の分析でよいものという形で、可視化の対象を分けたりクエリの頻度を変えることでコストを最適化することができます。

可視化するサービスも用途に応じて分ける場合、BI のようにアドホックに分析する場合は、Amazon QuickSight を併用するという構成も考えられます。

用途に応じて分析サービスを分けるという構成はよく見られますが、ユーザー観点では使うツールが増えるというデメリットがあるので、別のサービスや専用アプリの利用も検討するのがよさそうです。
複数のツールを使う場合、用途に応じて使うユーザーや部門が異なるケースなら問題なさそうですが、そうではないケースもあると思います。まだ自分の中でいい案が思いついていないので別途検討しようと思います。

最後に

今回は、これまでの経験を元に今の時点で分かったポイントについて共有させていただきました。
話したいことが多く表現できなかった部分もあったと思いますが、今回の登壇にて参加者の皆様のお役に立つ情報が一つでもあれば幸いです。

以上です。